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FIELD OF THE INVENTION 

TliepresmtmvenlionrelBtes to network synchronization and mjrepa^^ 
synchronizing the playback of amnltimedia event on aphnality of client 
10 apparatuses. 

BACKGROUPW OF THE INVENTION 

15 Systm8SuchastheInternettypicallyaiepoint-to-point(orunioa5t)systemsin 

which amessage is converted into a series of addressed packets which are routed 
fromasoTircenodethroughapluiaKtyofroutcastoadestinationnode. Mmost 
commnmcationprotocols the packet inclndesaheadervAicA contains the a^ 
of the source and the destmation nodes as well as a sequence nninber which specifies 
20 the packet's order in -flie message. 

Mgeneral. these systems donot have the cs^iHtyofbroadcastingamessage 
a source node to all the olhernodes in die netwodc because such a capabiKty is tardy 
ofnmchuse and could easily overloadthenetwodc However, there are situations 
wh«e it is desiiBbie for one node to conununicate with some subset of an thenodes. 

For example/niulti.partyconfa:encmgcq)ri)ility analogous to to^ 
public tdephone system and broadcasting to a limited number of nodes are of 
conaderablemtaestto users ofpacket-switchednetworks. Tosatisfysnch 
demands, packets destined for several recipients have been encapsulated in a miicast 
30 packet and forwarded from a source to a point in a netwodc where the packets have 
beenieplicated and forwarded on to all desned recipients. Tliis technique is known 
IP MuWcastmg and thenetworic over which such packets are routed is referred to 
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as the Multicast Backboae or MBONE. More recwitly, routers have become 
available which can route tiie multicast addresses (class D addresses) provided for in 
commumcation protocols sruch as TCP/CP and UDP/IP- A multicast address is 
essentially an address for a group of host computers who have indicated their desire 
5 to particrpate in that group. Thus, a multicast packet can be routed from a source 
node through a plurality of multicast routers (or mrouters) to one or more devices 
receiving the multicast packets. From &ere the packet is distributed to all the host 
computers that are members of the multicast group. 

1 0 These techniques have been used to provide on the Ihtemet audio and video 

confeencing as well as radio-like broadcasting to groups of interested parties. See, 
for example, K Savelz et al. MBONE Multicasting Tomorrow's Ihtemet (IDG 
Books Worldwide hic., 1996). 

1 5 Further details concerning technical aspects of multicasting may be found in the 
Intemet documents Request for Conaments (RFC) 1 1 12 and 1458 ^ch are 
reproduced at Appendices A and B of the Savetz book and in D. P. Brutaman et al., 
•'MBONE provides Audio and Video Across the hitem^," IEEE Computer, VoL 27, 
No. 4, pp. 30-36 (April 1 994)> all of which are incoxporated herein by refcroice. 

20 

Multimedia computer s>^ems have become increasingly popular over the last 
several years due to their versatility and their interactive presentation style. A 
multimedia conotput^ system can be defined as a computer system having a 
combination of video and audio outputs &r presentation of audio-visual displays. A 

25 modem multimedia conq^uter system typically includes one or more storage devices 
such as an optical drive^ a CD-ROM, a hard drive, a videodisc, or an audiodisc, and 
audio and video data are typically stored on one or more of these mass storage 
devices. In some file formats ihe audio and video are interleaved together in a smgle 
file, while in other formats the audio and video data are stored in different files, 

30 many times on difTexent storage media. Audio and video data for a multimedia 

display may also be stored in separate computer systems that are netwozked together. 
In this instance, tihe conn^uter system presenting the multimedia display would 
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receive a portion of the necessary data from the other computer system via the 
network cabling. 

Graphic hnages used in Windows multimedia applications can be created in eith^ of 
5 two wsysj these being bit-mapped images and vector-based images. Bit-m^ed 
images comprise a plurality of picture elements (pixels) and are created by assigning 
a color to each pixel inside the image boundary. Most bit-mapped color images 
require one byte per pixel for storage, so large bit-m^ped images create 
correspondingly large files. For example, a full-screen, 256-color image in 640-by- 
10 480-pixel VGA mode requires 307,200 bytes of storage, if the data is not 

compressed. Vector-based images are created by deiSning the end points, thickness, 
color, patt^ and curvature of lines and solid objects cornprised within the image. 
Thus, a vector-based image includes a definition which consists of a numerical 
representation of the coordinates of the object, referenced to a comer of the image. 

15 

Bit-mspped images are the most prevalent type of image storage format, and the 
most common bit-m^ed-image file formats axe as follows. A file format lefeired 
to as BMP is used for Windows bit-map files in 1-, 2-, 4-, 8-, and 24-bit color 
dq)ths. BMP files contain a bit-map h^der that defines the size of the images the 

20 number of color planes, the type of compression used (if any), and the palette used. 
The Windows DIB (device-independent bit-map) fomiat is a variant of the BMP 
fonnat that includes a color table defining the RGB (red green blue) values of the 
colors used. Other types of bit-m^ fomiats include the TIF (tagged image Jfonnat 
file), the PCX (Zsoft Personal Computer Paintbrush Bitma^j) file format, the GIF 

25 (graphics interchange file) fbnnat, and fte TGA (Texas Instruments Graphic 
Architecture) file fonnat 

The standard Windows format for bit-mapped images is a 2S6-color device- 
independent bit m^ (PJB) with a BMP (the Windows bit-m^ped file format) or 
30 sometimes a DIB extension. The standard Windows format for vector-based images 
is referred to as WMF (Windows meta file). 



Full-motion video implies that video images shown on the computer's screen 
simulate those of a television set with identical (30 frames-per-second) frame rates, 
and that these images are accompanied by high-quality stereo sound* A large 
amount of storage is required for high-resolution color iioagcs, not to mention a fiill- 
5 motion video sequence. For example, a single frame of NTSC video at 640-by'400- 
pixel resolution with 16-bit color requires 512K of data per frame. At 30 flames per 
second, over 1 5 Megabytes of data storage are required for each second of fidl 
motion video. Due to the large amount of storage required for full motion video, 
various types of video compression algorithms are used to reduce the amount of 
10 necessary storage. Video compression can be p^ormed either in real-time, i.e., on 
the fly during video capture, or on the stored video file after the video data has been 
captured and stored on the media, fri addition, dififereut video compression methods 
exist for still graphic images and for full-motion video. 

15 Examples of video data compression for still graphic unages are RLE (nm-length 
encoding) and IPEG (Joint Photographic Experts Group) compression. RIB is the 
standard compression method for Wndows BMP and DIB files. The RLE 
conq)ression method operates by testing for duplicated pixels ia a singje line of the 
bit map and stores the number of consecutive duplicate pixels rather than the data for 

20 the pixel itself JPEG conq)ression is a group of related standards that provide either 
lossless (no image quali^ degradation) or lossy (imperceptible to severe 
degradation) coropression types. Althou^ JPEG coropression was designed for the 
compression of still images rather flian video, several manufacturers supply JPEG 
compression adapter cards for motion video applications. . 

25 

In contrast to compression algorithms for still images, most video compression 
algorithms are designed to compress full motion video. Video compression 
algorithms for motion video generally use a conc^t refeired to as interframe 
con^ression, which involves storing only the differences between successive frames 
30 in the data file. Merfianie compression begins by digitizing the entire linage of a 
key frame. Successive fi:ames are compared wifli the key frame, and only the 
differences between the digitized data from the key frame and from the successive 
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jframes are stored. Periodically, such as when new scenes are displayed, new key 
firames are digitized and stored, and subsequent comparisons begin from this new 
reference point It is noted that interframe compression ratios are content-depaident, 
i.e., if the video clip being compressed inchides many abrupt scene transitions from 
5 one image to another, the compression is less efficient. Exan^)les of video 

compression which use an interframe compression technique are MPEG, DVI and 
Indeo, among others. 

MPEG (Moving Pictures Experts Group) compression is a set of methods for 
1 0 compression and decompression of full motion video images that uses die interframe 
coiEpression technique described above. The MPEG standard requires that sound be 
recorded simultaneously with the video data, and the video and audio data are 
interleaved in a single file to attempt to maintain the video and audio synchronized 
during playback. The audio data is typically compressed as well, and the MPEG 
15 standard specifies an audio conipiession method referred to as ADPCM (Ad^tive 
Difiorential Pulse Code Modulation) for audio data. 

A standard referred to as Digital Video Interactive (DVI) format developed by hitel 
Coiporadon is a compression and storage format for fidl-motion video and faig^ 

20 fidehty audio data. The DVI standard uses interframe compression techniques 

similar to diat of the MPEG standard and uses ADPCM compression for audio data. 
The compression method used in DVT is referred to as RTV 2.0 (real time video), 
and this compression method is incorporated into Mel's AVK (audio/video kernel) 
sofbvare for its DVI product line. IBM has adopted DVI as the standaiji for 

25 displaying video for its Ultimedia product Mne. The DVI file format is based on flie 
Intel i750 chipset and is siqjported through the Media Control Interface (MCI) for 
Windows. Microsoft and Intel jointly announced the creation of die DV MCI 
(digital video media control interfece) command set for Window 3.1 in 1 992. 

30 Tlie Microsoft Audio Video Merleaved (AVI) format is a special compressed file 
structure fonnat designed to enable video images and synchronized sound stored on 
CD-ROMs to be played on PCs with standard VGA displays and audio adapter 




cards. The AVI compression method uses an interframe method, i.e., the differences 
between successive frames are stored in a manner similar to die compression 
methods used in DVI and MPEG. The AVI format uses symmetrical software 
compression-decompression techniques^ i.e,, both compression and decompression 
5 aie performed in real time. Thus AVI files can be created by recording video images 
and sound in AVI foraaat fibom a VCR or television broadcast in real time, if enough 
free hard disk space is available. 

Despite diese compression algorithms, it is very difficult to simultaneously multicast 
1 0 multimedia material due to bandwidth restraints. This problem is unavoidable with 
present technology since such large amoimts of data must be transferred ovct 
networks such as the Internet from a single host server to numerous client 
computers. 



15 



-7- 

SUMMARY OF THE INVENTION 

A system, method and article of manufacture are provided for synchronizing an 
event on a plurality of a client apparatuses. First, an event is stored in a memory 
5 storage device. The client apparatuses and a host computer are adapted to be 
-connected to a network. La operation^ information is transmitted from the host 
computer to the memory storage device utilizing the network. This allows for the 
simultaneous playback of the event on each of the client apparatuses. 

10 In one embodiment^ the event includes a video and audio presentation such as 

movie, a concert, and/or a theatrical event The information may also include a start 
time wh^ the playback of the event is to begin on each of the client apparatuses. 
Further, an ending time may be included when the playback of the event is to end on 
each of the client apparatuses. 

15 

!6i a primary aspect of &e present invention, the memory storage device includes a 
digital video disc (DVD) player. Furth^, fee information includes chapter 
information associated with the DVD. As an option, input may be received from the 
user, and used to alter the playback of the event 

20 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will be better imderstood when consideration is given to the following 
detailed description tihereof. Such description makes reference to the annexed 
5 drawings wherein: 

Figure 1 is a schematic diagram of a hardware implemoitation of one embodiment 
of flie present invention; 

1 0 Figure 2 ifiustrates a flowchart delineating a method for synchronizing an event on a 
plurality of client apparatuses in accordance wifli one embodiment of the present 
invention; 

Figure 3 illustrates a flowchart delineating a method for storing synchronization 
1 5 information for subsequent playback of an event in accordance with one 
embodimmt of the present invention; 

Figure 4 illustrates a flowchart settmg forth a method for providing overlays during a 
synchronized event on a plurality of client apparatuses in accordance with one 
20 embodiment of the present invention; 

Figure 5 illustrates a flow diag^ram for delayed synchromzation of an event on a 
plurality of client apparatuses in accordance wifii one embodiment of the present 
invention; 

25 

Figure 6 illustrates a flow diagram for providing information on a synchronized 
event on a plurality of client apparatuses in accordance with one onbodiment of the 
present invention; 

30 Figure 7 illustrates a meChod for creating a synchronizer object in order to playback 
an event simultaneously on a plurality of client apparatuses in accordance with one 
embodiment of the present invention; 
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Figure 8 illustrates a flowchart for a£fording a scheduler object adapted to facilitate 
the playback of an event simultaneously on a plurality of networked client 
apparatuses in accordance with one embodiment of the present invention; 

5 

Figure 9 is a flowchart delineating a method for identifying a plurality of events 
which are played back simultaneously on a phuality of networked client apparatuses 
in accordance with one embodiment of the present irrvention; 

10 Figure 10 shows a flowchart delineating a technique for interfacing aplurality of 
different types of playback devices of cUent ^paratuscs which are networked to 
simultaneously playback an event in accordance with one embodiment of the present 
invention; 

1 5 Figure 1 1 illustrates the maxm^ in which a layer &ctory is created in accordance 
with one embodiment ofUxe present invention; 

Figure 12 illustrates the maimer in yMc3i user requests are processed in accordance 
with one embodiment of the presait invention; 

20 

Figures 13-16 illustrate various class/component diagrams in accordance with one 
embodiment of the present invention; 

Figure 17 illustrates a logical sequence diagram in accordance with one embodiment 
25 of the present invention; 

Figure 18 illustrates a logical sequence diagram that shows sender side collaboration 
in accordance with one embodiment of the present inventioi^ and 

30 Figure 19 illustrates a logical sequence diagram showing client side collaboration m 
accordance with one embodiment of the present inventioiL 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Figures 1-19 illustrate a system for synchromzing an event on a plurality of client 
apparatuses. Prior to use, an event is stored in memory on at least one of the client 
^aratuses. Such client ^paratuses are adapted to be connected to a network along 
with a host computes). In operation^ information is traosmitted JSrom the host 
computer to the at least one client z^paratus utilizing the network: This information 
allows &SI the simultaneous and synchronous playback of the event on each of the 
client apparatuses. 



Id various embodiments, the client apparatuses may take the £>rm of computers^ 
televisions, stereos, home appliances, or any other types of devices. In one 
embodiment, the client apparatuses and the host computer each include a compute 
such as an IBM cQjiq>atible computer, Apple Macintosh computer or UNIX based 
15 workstation. 

A representative hardware environment is dq>icted in Figure 1, which illustrates a 
typical hardware configuration of a woikstation in accordance with a prefeired 
embodiment having a central processing unit 110, such as a microprocessor, and a 

20 mnnber of other units interconnected via a system bus 112. The workstation shown 
in Figure 1 includes a Random Access Msmoxy (RAM) 1 14, Read Only Memory 
(RDM) 116, an I/O adaptei: 118 for coimeatingperq)heral devices such as disk 
storage units 120 {i.e. DVD playback device) to the bus 112, a user interface ada^tra- 
122 for connecting a keyboard 124, a mouse 126, a speaker 128, a microphone 132, 

25 and/or other user inter&ce devices such as a touch screen (not shown) to the bus 
112, communication adapter 134 for coimecting the wodcstation to a commxmicatiion 
networic (e.g.-, a data processing network) and a dispby adapter 136 for connecting 
the bus 112 to a display device 138. Hie workstation tjpically has resident thereon 
an operating system such as the Microsoft Windows NT or Windows/95 Operating 

30 System (OS), the IBM OS/2 operating system, the MAC OS, or UNK operating 
system. Those skilled in the art will appreciate that the present invention may also 
be implemented on platforms and operating systems other than those mentioned. 




A preferred embodiment is written using JAVA, C, and the C-H- language and 
utilizes object oriented prograimning methodology. Object oriented programming 
(OOP) has become increasingly used to develop complex applications. As OOP 
5 moves toward the mainstream of software design and development, various software 
solutions require adaptation to make use of the benefits of OOP. A need exists for 
these principles of OOP to be applied to a messaging interfece of an electronic 
messagbg system such that a set of OOP classes and objects for the messagjuog 
interface can be provided. 

10 

OOP is a process of developing computer software using objects, including the steps 
of analyzing the problem, designing the system, and constructing the program. An 
object is a software package that contains both data and a collection of related 
structures and procedures. Since it contains both data and a collection of structures 

1 5 and procedures, it can be visualized as a self-sufBcienl component that does not 
require other additional structures, procedures or data to perform its specific task. 
OOP, therefore, views a computer program as a collection of largely autonomous 
components, called objects, each of which is responsible for a specific task. This 
concept of packaging data, structures, and procedures togeth^ in one component or 

20 module is called encapsulation. 

In general, OOP components are reusable software modules which present an 
interface that conforms to an object model and which are accessed at run-time 
through a component integration architecture. A component integration architecture 

25 is a set of architecture mechanisms which allow software modules in di£ferent 

process spaces to utilize each others capabilities or functions. This is generally done 
by assuming a common component object model on which to build the architecture. 
It is worthwhile to difterentiate between an object and a class of objects at this point 
An object is a single instance of the class of objects, vAdjch is often just called a 

30 class. A class of objects can be viewed as a blueprint, ftom which maiiy objects can 
be formed. 
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OOP allows the programmer to create an object that is a part of another object For 
example, the object representing a piston engine is said to have a composition- 
relationship with the object representing a piston. In reality, a piston engine 
coxiq)rises a piston, valves and many other components; the &ct that a piston is an 
5 element of a piston engme can be logically and scmanticaUy represented in OOP by 
two objects. 

OOP also allows creation of an object that "depends from" another object If there 
are two objects, one representing a piston engine and the other rqpresenting a piston 

1 0 engine wherein the piston is made of ceramic, tiien the relationship between the two 
objects is not that of composition. A ceramic piston engine does not make up a 
piston engine. Ra&CT it is merely one kind of piston engine that has one more 
limitation than the piston engine its piston is made of ceramic. la this case, the 
object representing the ceramic piston oagine is called a derived object, and it 

15 inherits all of the aspects of the object rq)rcsenting flie piston engine and adds 
further limitation or detail to it The object rq)resenting the ceramic piston engine 
"dq)ends from" the object representing fihe piston engine- The relationship betwc«i 
these objects is called inheritance. 

20 When &e object or class representing the c^andc piston engine inherits all of the 
aspects of the objects rq)rKenting the piston engine, it inherits the themud 
characteristics of a standard piston defined in the piston engme class. However, the 
ceramic piston engme object overrides these ceramic specific thermal characteristics, 
which are typically different from those associated wiQi a metal piston. It skips over 

25 the origiiial and uses new frmctionsrdated to cenomc pistons. Diffmnt kinds of 
piston engines have different characteristics, but may have the same underlying 
functions associated with it (e.g,^ how many pistons in the engine, ignition 
sequences, lubrication, etc.). To access each of these functions in any piston cxiffne 
object, a programmer would call fte same functions with the same names, but each 

30 type of piston engine may have different/overriding implementations of fimctions 
behind the same name. This ability to hide different ino^lementatians of a junction 
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behind the same name is called polymoiphism and it greatly simplifies 
communicatioxi among objects. 

With the concepts of composition-relationship, encapsulation, inheritance and 
5 polymorphism, an object can represent just about anything in the real world. Jn fact, 
one's logical perception of the reality is the only limit on detennining the kinds of 
things that can become objects in object-ori^ted software. Some typical categories 
are as follows: 

• Objects can represent physical objects, such as automobiles in a tra£Sc-fIow 

1 0 simulation, electrical components in a circuit-design program, countries in an 

economics model, or aircraft in an air-trafGc-controI s^^em. 

• Objects can represent elements of the computer-user -environment such as 
windows, menus or gr^hics objects. 

• An object can rq>resent an inventory, such as a personnel file or a table of the 
15 latitudes and longitudes of cities. 

• An object can represent user-defined data types such as time, angles, and 
complex numbas, or points on the plane. 

With this enormous capability of an object to represent just about any logically 
20 separable matters, OOP allo^ the software developer to design and implement a 
computer program that is a model of some aspects of reality, wheflier that reality is a 
physical entity, a process, a system, or a composition of matter. Since &e object can 
represent airything, the software developer can create an object which can be used as 
a component in a larger software project in the future. 

25 

If 90% of a new OOP soflvrare program consists of proven, existing components 
made fiom piieexisting reosable objects, flien only the remaming 10% of the new 
software project has to be written and tested &om scratch. Smce 90% already came 
from an inventory of extensively tested reusable objects, the potential domain from 
30 which an earor could originate is 10% of the program. As a result, OOP enables 
software developers to build objects out of other, previously built objects. 
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This process closely resembles complex machineiy being built out of assemblies and 
sub-assemblies. OOP technology, therefore, makes software engineering more like 
hardware engineering in that software is birilt from existmg conq)onents, which are 
5 available to the developer as objects. All this adds 1:5) to an improved quality of the 
software as well as an increased speed of its development 

Programming languages are beginning to fully support the OOP principles, such as 
encapsulation, inheritance, polymorphism, and composition-relalionship. With the 

1 0 advent of flie C++ language, many commercial software developers have embraced 
OOP. C++ is an OOP language that ofiFers a fest, machine-executable code. 
Furthermore, C++ is suitable for both commercial-application and systems- 
programming projects. For now, C++ j^ears to be the most popular dioice among 
many OOP programmers, but there is a host of other OOP languages, such as 

15 Smalltalk, Common lisp Object System (CLOS), and EififeL Additionally, OOP 
capabilities are being added to more traditional popular computer programming * 
languages such as Pascal. 

The benefits of object classes can be summarized, as follows: 
20 * Objects and their corresponding classes break down complex ptogramiiiing 
problems into many smaller, simpler problems. 
• Ecc^sulation enforces data abstraction through the organization of data into 
small, independent objects that can communicate vnSi each other. 
Encapsulation protects the data in an object from accidental damage, but 
25 allows other objects to interact with that data by calling &e object's member 

functions and structures. 
» Subclassmg and inheritance make it possible to extend and modify objecte 
through deriving new kinds of objects from the standard classes available in 
the system. Thus, new c^abilities are created wifliout havmg to start from 
30 scratch. 
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• Polymorphism and multiple inheritance make it possible for different 
progranmiers to mix and match charact^stics of mairy different classes and 
create specialized objects that can still woik with related objects in 
predictable ways. 

5 • Class hierarchies and containment hierarchies provide a flexible mechanism 
for modeling real-world objects and the relationships among fliem. 

• Libraries of reusable classes are useful in many situations, but they also have 
some limitations. For example: 

• Complexity. In a complex systemi, tiie class hierarchies for related classes 
1 0 can become extremely confysing, with many dozens or even hundreds of 

classes. 

• Flow of control. A program written wifli the aid of class libraries is still 
responsible for the flow of control (i.e., it must control the interactions 
among all the objects created fiom a particular library). The programmer has 

15 to decide which functions to call at what times for vt^iich kinds of objects. 

• Duplication of effort Although class libraries allow programmers to use and 
reuse many small pieces of code, each programmer puts those pieces together 
in a different way. Two different programme can use the same set of class 
libraries to write two programs that do ^actiy the same thing but whose 

20 internal structure (i.e,, design) may be quite different, depending on hundreds 

ofsmall decisions each programmer makes along the way. inevitably, 
sixnilar pieces of code end up doiiig similar tfain^ in slightly different ways 
and do not woric as well together as they should. . 

25 Class libraries.are vary flexible. As programs grow more cornplej^, more 

programmers are forced to reinvent basic solutions to basic problems over and over 
again. A relatively new extension of the class library concq)t is to have a jS^mewoik 
of class libraries. This fiamework is more complex and consdsts of siguificant 
collections of collaborating classes that capture both the small scale patterns and 

30 major mechanisms that implement the cormnon requirements and design in a 
specific application domaiiL They were first developed to free application 
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prograimners firom the chores involved in displaying menus^ windows, dialog boxes, 
and other standard user interface elements for personal computers. 

Framewoiks also r^resent a change in the way programmers think about the 
5 interaction between the code they write and code written by others. In the early days 
of procedural programming, the programmer called libraries provided by the 
operating system to perform certain tasks, but basically the prograin executed down 
the page from start to finish, and the programmer was solely responsible for the flow 
of control. This was appropriate for printing out paychecks, calculating a 
1 0 mathematical table, or solving other problems with a program fliat executed m just 
oneway. 

The development of graphical user interfaces began to turn this procedural 
programnodng arrangement inside out These interfeces allow "Bie user, raUier than 

1 5 program logic, to drive the program and decide when certain actions should be 

performed. Today, most personal computer software accomplishes this by means of 
an event loop which monitors the mouse, keyboard, and other sources of external 
events and calls tiiie ^propriate parts of Sie programmer's code according to actions 
that tiie user perfonns. The progranmer no longer determines the order in which 

20 events occur. Instead, a program is divided into sqparate pieces that are called at 
impredictable times and in an unpredictable order. By relinquishing control in this 
way to users, the developer oreates a program that is much easier to use. 
Nevertheless, individual pieces of the program written by the developer still call 
libraries provided by the operating system to accomplish c^tain tasks, and the 

25 programmer must still determine &e flow of control wifhin each piece after it's 
called by the event loop. Application code still "sits on top of* the system. 

Bven event loop programs require programmers to "write a lot of code that should not 
need to be written separately for every application. The concept of an application 
30 fiamework carries the event loop concq>t further, Insteadof dealing with all the 
nuts and bolts of constructing basic menus, windows, and dialog boxes and then 
making these things all v/oik toge&er, programmers using application ftamewoijcs 
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stait with working application code and basic user interface elements in place. 
Subsequently, fliey build from there by replacing some of the generic capabilities of 
the framework with the specific capabilities of the intended application. 

5 implication frameworks reduce the total amount of code that a programmer has to 
write from scratch. However, because the framework is really a generic application 
that displays windows, supports copy and paste, and so on, the programmer can also 
relinquish control to a greater degree than event loop programs permit The 
framework code takes care of almost all event handling and flow of control, and the 
10 progranam^s code is called only when the framework needs it (e.g., to create or 
manipulate a proprietary data structure). 



A programmer writing a framework program not only relinquishes control to the 
user (as is also true for event loop programs), but also relinquishes fhs detailed flow 
1 5 of control within the program to the framework. His approach allows the creation 
of more complex systems that work together in interesting ways, as opposed to 
isolated programs, having custom code^ being created over and over again for similar 
problems. 

20 Thus, as is explained above, a framework basically is a collection of cooperating 
classes that make iq> a reusable design solution for a given problem domain. It 
typically includes objects that provide default behavior (e.g., for menus and 
windows), and programmesrs use it by inheriting some of that de&ult behavior and 
overriding other bdiavior so that the framework calls apphcation code at the 

25 appropriate times. 

There are three main differences between firameworks and class libraries: 
• Behavior versus protocol. Class libraries are essentially collections of 

behaviors that you can call \^en you want those individual behaviors in your 
30 program. A framework, on frie other hand, provides not only behavior but 

also the protocol or &et of rules that govern the ways in which behaviors can 
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be combined, including rules for what a programmer is supposed to provide 
versus what the ftamewoik provides. 

• Call versus ovenide. Witib a class library, the code the programmer 
instantiates objects and calls their member functions. It's possible to 
instantiate and call objects in the same way with a firamewoik (i.e., to treat 
the fiamewoiic as a class library), but to take fiill advantage of a fi:amework*s 
reusable design, a programmer typically writes code that overrides and is 
called by flie framework. The fiamework manages the flow of control among 
its objects. Writing a program involves dividing responsibilities among the 
various pieces of software that are called by the fiamework rath^ than 
specifying how the different pieces should work together. 

• Implementation versus desigtu With class libraries, programmers reuse only 
implementations^ whereas wi& frameworks, &ey reuse design. A framework 
embodies the way a family of related programs or pieces of software work. It 
represents a generic design solution that can be adapted to a variety of 
specific problems in a given domain. For example, a single framework can 
embody tfie way a user interface woiks, even though two different user 
intet&ces created with the same fiamework mi^t solve quite difif^ent 
int^ace problexns. 

Thus, through the development of fiamewodiis fi>r solutions to various problems and 
programming tasks, dgnificant reductions in the desiga and development effort for 
software can be achieved. A pre^rred embodiment ofHiQ invention utilizes 
HyperText Madaip Language (HTML) to impl^ent documents on the Intemet 
together with a general-purpose secure communicalion protocol for a transport 
medium between the client and the Newco. HTTP or other protocols could be 
readily substituted for HTML without undue experimentation, formation on these 
products is available in T. Bemers-Lee, D. Connoly, "RFC 1866: Hypertext Maifcup 
Language - 2.0" (Nov, 1995); and R. Fielding, H, Fiyst)*, T. Bemers-Lee, J. Gettys 
and LC. Mogul, "Hypertext Transfer Protocol - HTIP/l.l: HTTP Woddng Group 
Internet Draft" (May 2, 1996). HTML is a simple data format used to create 
hypertext documents that are portable fixmi one platform to another. HTML 
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docum^ts are SGML documents with geaeric semantics that are appropriate for 
r^resentmg infonnatioii from a wide range of domains, HTML has been in use by 
the World-Wide Web global information initiative since 1990. HTML is an 
E5)plication of ISO Standard 8879; 1986 Mbrmation Processing Text and OfSce 
5 Systems; Standard Generalized Markup Language (SGML), 

To date, Web development tools have been limited in dieir ability to create dynamic 
Web applications which span from client to server and interoperate with existing 
computing resources. Until recently, HTML has been the dominant technology used 
10 in development of Web-based solutions. However, HIML has proven to be 
inadequate in the following areas: 

• Poorperfonnance; 

• Restricted user inter&ce capabilities; 

• Can only produce static Web pages; 

15 • Lack of interopOTbility with existing plications and data; and 

• Inability to scale. 

Sun Microsystooa's Java language solves many of the client-side problems by: 

• Improving performance on &e client side; 

20 • Eaabling the creation of dynamic^ real-time Web ^jphcations; and 

• Providing tiie ability to create a wide variety of usa- intcrfece components. 

With Java, developeis can create robust User Interface (UI) conaponents. Custom 
"widgets" (eg., real-time stock tickers, animated icons, etc.) can be created, and 
25 climt-side performance is inqjToved. UnlikeHTMLi, Java supports flie notion of 
client-side validation, ofQoading ^propriate processing onto the client for improved 
performance*. Dynamic, real-time Web pages can be created. Using the above- 
mentioned custom UI components, dynamic Web pages can also be created. 

30 Sun's Java language has emerged as an industiy-recognized langoa^ for 

"programming die lotemet" Sun defines Java as: "a sinqile, object-oriented. 
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distributed, interpreted, robust, secure, architecture-neutral, portable, high- 
perfonnance, multitiffeaded, dynamic, buzzword-compliant, general-purpose 
prograxmniag language. Java supports programming for the Internet in the fonn of 
platfonn-independent Java applets.*' Java applets are small, specialized ^plications 
5 that comply with Sun's Java Application Programming Interface (APQ allowing 
developers to add "interactive content" to Web documents (e.g., sirriple animations, 
page adornments, basic games, etc.). Applets execute wiflm a Javarcompatible 
browser (e.g., Netsc^e Navigator) by copying code &om the server to client. From 
a language standpoint Java's core feature set is based on C++. Sun*s Java literature 
1 0 states that Java is basically, "C++ with extensions fiom Objective C for more 
dynamic method resolutioiL" 

Another technology that provides similar function to JAVA is provided by Microsoft 
and ActiveX Technologies, to give developed and Web designers wherewithal to 

1 5 build dynamic contort for the Internet and personal conoputexs. ActiveX includes 
tools for developing animation, 3-D virtual reality, video and other multimedia 
content The tools use Internet standards, work on multiple platforms, and are being 
supported by over 1 00 companies. The group's building blocks are called ActiveX 
Controls, small^ &st components that enable developers to embed parts of software 

20 in hypertext marfaq) language (HTML) pages. ActiveX Controls work with a variety 
of programming languages including Microsoft Visual C++, Borland Delphi, 
Microsoft Visual Basic programming system and, in the future, ftficrosofl^s 
development tool for Java, code named "Jakarta." ActiveX Technologies also 
includes ActiveX Server Framework, allowing developers to crrate server 

25 plications. One ofordinarysldU in the art readily recognizes that ActiveX could 
be substituted ifor JAVA wifihout undue experimentation to practice the invention. 

Synchronization Overview 

30 Figure 2 illustrates a flowchart delineatmg a method for synchronizing an event on a 
plurality of client paratuses. First, in operation 200, an event is stored in memory 
on at least one of the client apparatuses. In various embodiments, the memory may 
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take the form of an eleotromagnetic medium, or any type of optical storage device, 
i.e. CD-audio. In aprimary aspect of the present invention, the memory includes a 
digital video disc (DVD) (audio or video). Further, for reasons that will soon 
become apparent, the information includes chapter information associated with the 
5 DVD. In such embodiment where the memory is portable, the user may be required 
to purdiase the memory, i.e, DVD, in order to participate in a synchronized evKit, 
thus increasmg the sale of DVD*s. 

It should be noted that Ihe event need not be necessarily stored in memory on all of 
10 the cheat apparatuses, but rather stored on one or some of the client ^aratoses and 
streamed to the remaining client apparatuses at variant rates. This may be feasibly 
accomplished if flie client apparatus(es) containing the stored event has a high- 
bandwidtfa connection with the remaining client ^paratuses. For example, the client 
apparatus(es) containing the stored event may include a server that has a connection 
15 to a plurality of televisions via a cable network, i.e. WEBTV. Similar functionality 
may be achieved via a broadcast medium, nxe present invention is thus flexible by 
having an ability to host user events and corporative events. 

In one embodimmt, the event includes a video and audio presentation such as 
20 movie, a concert, and/or a theatrical event It should be noted, however, that the 
event may included any recording enable of being played back for OTtertainment, 
education, informative or other similar purposes. 

In use, the cli^t apparatuses and a host con^uter are ad^ted to be connected to a 
25 . network. Such network may include a wide^ local or any other ^e of 

communicatiori network. For example, a wide area network such as the Internet may 
be employed which operates usmg TCP/IP or IPX protocols. 

In operation 202, information is transmitted fiom ^e host con:q)Uter to the 
30 appropriate client apparatuses utilizing the network- This information allows for the 
simultaneous and synchronous playback of die event on each of the cli^t 
apparatuses. In one embodiment, the information may also include a start tune when 
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the playback of the event is to begin on each of the client apparatuses. Furttier, an 
ending time may be included when the playback of the event is to end on each of the 
chent apparatuses. Still yet, ''play" command information may be sent to the client 
apparatuses at the start tune. As an option, input may be received &om the user, and 
5 used to alter the playback of flie event. The host server, or synchronization server, 
can also control various streams of a variant rate and difii^^t hardware associated 
with those streams. 

The present invention thus has the ability to synchronize video playback for one or 
10 multiple (thousands) users fiom one or multiple physical locations, and to 
synchronize with extemal video, audio and/or data streams. 

Users of the present invention are at multiple physical locations and host servexs 
may also be at different locations. Hie present invention is thus a scalable syst^ 
1 5 which is capable of servicing an unlimited number of users. Since the content is 
local to the usct machine, no high network bandwidth is required. 

History Download Capabilities 

20 Figure 3 illustrates a flowchart delineating a method for storing synchronization 
information for subsequrait playback of an event Initially, in operation 300, an 
event is stored in memory on at least one of the client ^paratuses, as set forth 
earlier. These client apparatuses are adapted to be connected to a netwoik along 
with a host computer during use. 

25 

In operation 302, information is stored on the host computes) for allowing the 
simultaneous playback of the event on each of fixe client ^aratuses. In one 
embodiment, the information may include a history and data associated with the 
synchronous playback. la particular, the histoiy may include any overlaid 
30 material(as will be described hereinafter in greater detail), any specific commands 
aflFecting the playback of flie nifbnnation, or any other type of general information, 
i.e. start time, end time, etc. 
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Jh operation 304, the information may be downloaded utilizing the network at any 
time after the synchronons playback of the event. Such downloaded information 
may then be used for playback after the simultaneous playback of the event As 
such, fee present invention has the ability to allow users to download a history and 
data associated with a particular synchronization event and play it later. 

Overiav Synchronization 

Figure 4 illustrates a flowchart settbg forth a method for providing overlays during a 
synchronized event on a plurality of client apparatuses or any other source. First, in 
operation 400, a plurality of client apparatuses are connected via a network. In 
operation 402^ an event may be simultaneous^ played back on the client q>paratuses 
utilizing the network, as set forth earlier. 

During the playback of the event, visual and/or audio matedal rhay also be overlaid 
on the event based on input received £:om at least one of the client apparatuses. See 
operation 404. This may be accomplished by transmitting the overlay material from 
one of the chent ^paratuses to the host con^uter or any other server, and 
multicasting the same to the rmiaining client ^paratuses. 

As an option, the overiay material may include annotations on a display of the client 
apparatus. For example, the overlay material may include sketches ^ch are 
iiiputted by way of a stjdus-based input screen or a keyboard or the like, along with a 
voiceover inputted by way of a microphone or voice synthesizer. Such capability 
may also be qiiite valuable in an educational environm^ 

In one embodiment, the overlay materia] may also be displayed on each of the client 
apparatuses utilizing the network. This allows each of the users to e)cperience the 
overlay in real-time during the simultaneous playback of the event As an option, 
the user inputting the overlay material may select vfinch users may experience the 
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overlay material. The client apparatus that provided the overlay material may also 
be identified to the iisers experieDcing the overlay material. 

It should be noted that varioiis bi-directional communication may be enabled for 
allowing data to travel to and from the server. For instance, the playback of the event 
the client apparatuses may be altered in any feasible way based on input from a user 

Late Synchronization 

Figure 5 illustrates a flow diagram for delayed synchronization of an event on a 
plurality of client apparatuses. First, in operation 500, a plurality of client 
apparatuses are connected via a netwoik and an event is stored in memory on the 
client apparatuses. The event is then simultaneously played back on the client 
^aratuses utilizing the netwoik, as set forth earlier. Note operation 502. 

During the simultaneous playback, a request may be received from one of the client 
apparatuses for that particular to be included in the synchronized event, as set forth 
in operation 504. This request may be received after the synchronized event has 
already begun while it is still playing. Further, the request may be submitted via a 
site on a network, i.e. website. 

Jn response to the request, information is transmitted in operation 506 to the 
requesting chent apparatus utilizing the network. This information is ad^ted for 
identij^g a location in the memory where fbe event is currently being played back. 
This allows the simultaneous playback of the event on &e requesting client 
q)paratus. 

The end users are thus able to come in at a later time and to be synchronized wifli the 
event Targeted synchronization and various filters criteria can be applied to target 
different audiences. Also language and cultural differences can be taken into 
account StiU yet, the present invention may be adapted to address users on diS^nt 
hardware platforms (MAC, PC, set-top boxes). This may be accomplished by 
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identifying the user xising a cookie, a user profile which is identified by way of a log 
in, or a Bum Cut Area (BCA) of the disc. 

An example setting forth details relating to identifying DVDs will now be set forth, 
5 Hrst, a content owner (such as studio) requests use of the BCA on their DVDs. Based 
on request, the rq>licator (examples include WAMO, Panasonic, Nimbus, Technicolor, 
Moneer, Crest) adds miique BCA number to every DVD. Adding BCA number to each 
DVD requires a special (YAG) laser. This may be the veiy last step in Ihe 
manufecturing process. The BCA numbers for a specific DVD must then be watered 
10 into LaterActual's BCA database. Mbrmation to track includes: DVD title, i.e. 'Xost in 
Space"; BCA #/range, i.e. 12345687890; and Shipping Packagmg/Tracking Container, 
Le. Box 52221 to Hollywood Video. 

After the BCA number is added to the DVDs, the DVDs are packa^g/boxed for 
15 distribution to either the Distributor or the Retailer. It should be noted that many 
companies take multiple forms, so the r^licator and distributor may be one in the 
same. Also, some retaileis are large/important enough to get shipm^ts directly 
from replicator. The way in which the DVDs are packaging^shipped is very 
important because one nmst track the BCA numbers to actual shipping containers 
20 (box, etc.). Tliecefore tracking information must also be added to the BCA database. 

If packaged DVDs are then sent to distributor, the distributor also has mechanisms, 
i»e, scanners, input device^ and monitoring devices, in place for tracking based on 
their distributioiL For example^ JDeluxe may receive a '^package" of 100,000 copies 
25 of 'Xost in Space.** However, the distributor ships 10,000 to Retailor A and 5,000 to 
Retailer B. The distributor should be able to "input** retailer A and B's distribution 
information into Ihe system. Ideally, this becomes a seamless/automated process. 

Once file DVDs reach the retailer (either fi-om the replicator or distributor), then 
30 DVDs may be further divided and distributed to local stores/outlets. Jn such a 
situation, the retailer should be able to automatically 'track** distribution of these 
DVDs through to their stores. Over time^, all three entitities (replicator, distributor. 
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and retailer) are able to add tracking infonnation to BCA database. Due to 
complexity and dependencies on existing business systems, the retail tracking 
concept will be rolled out in phases: replicator first most likely with key retail 
accounts. The distributors will be brought in. Retailers will then begin to embrace 
5 the ability to track based on local outlet/store. 

By the foregoing design, easy depIo3naient is thus afforded and minimal hardware is 
required to allow the synchronization of content without significaut capital 
investments and with a very efficient control mechanism- Hie content delivery does 
1 0 not rely on high network bandwidth and is independent fiom the synchronization. 

Internet Server Application Program Interface (ISAPI) extensions will be used on the 
server. ISAPI extensions provide a mechanism to maintain a temporary or 
permanent connection with the users. These coimections allow the Synchronization 
15 Server to process request and to send the appropriate DVD connnands. The 

permanent connections are known as *Xeq) Alive" connections. IS API extension 
can also be used as an HTTP inter&ce to a more traditional sm^er, with all data 
returned as tect 

20- Ontheclientsidetfaeapproachistouse^butnotlimitedto Java I.l applets, to 

initiate event start-up for tiie Synchronization server. The advantage of using Java 
1 .1 applets is to achieve platform independence for existing and future Java-enabled 
devices. JavaScript wiU be used to provide user interfecenavi^tion by 'Svra^jping** 
the applet 

25 

An ISAPI (hitemet Server Application Program laterface) is a set of Windows 
program calls that let one write a Web server plication diat will run festerthan a 
Common Gateway fiiter&ce (CGI) appIicatioiL A disadvantage of a CGI application 
(or "executable file/' as it is sometimes called) is &at each time it is run, it runs as a 
30 separate process with its own address space, resulting in extra instructions that have 
to be perfomaed, especially if many instances of it are running on behalf of users. 
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Using IS API, you create a Dynamic Link Library (DLL) application file that can run 
as part of the Hypertext Transport Protocol (HTTP) plication's process and address 
space. The DLL Sles are loaded into the coniputer when HTTP is s^ed and remain 
there as long as they are needed; th^ dont have to be located and read into storage 
as firequently as a CGI application. 

Existing CGI applications can be converted into ISAPI application DLLs without 
having to rewrite their logic. However, they do need to be written to be thread-safe 
so that a single instance of the DLL can serve multiple users. 

A special kind of ISAPI DLL is called an ISAPI filter, which can be designated to 
receive control for every HTTP request One can create an ISAPI filter for 
encryption or decryption, for logging, for request screening, or for other purposes. 

One can write ISAPI servw extension DLLs (ISAs) that can be loaded and called by 
file HTTP server, Vsgis can fill out forms and click a submit button to send data to a 
Web server and invoke an IS Ay which can process the information to provide custom 
content or store it in a database. Web serv^ extensions can use infoimation in a 
database to build Web pages dynamically, and then send them to the client 
computers to be displayed. An application can add o&er custom fimctionahty and 
provide data to the cUent using HTTP and HTML. 

One can write an ISAPI filter. The filter is also a DLL that runs on an ISAPI- 
aiabled HTTP server. The filter registers'for notification of events such as loggjng 
onorURLmE^ping. When the selected events occur, the filt^ is called, and one 
can monitor and change the data (on its way fiiom &e server to the client or vice 
versa). ISAPI filters can be used to provide custom encryption or compression 
schemes, or additional au&entication methods. 

Bath server extensions and filters run in Ae process space of the Web server, 
providing an efBcient way to extend the server's cspabihties. 

Overall Component Des^ 
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The various fimctioDal components of the software associated with the present 
invention wiU now be set forth. Such components include a Java/JavaScript 
Component, Synchronizer Component, Layerlmpl Component, Business Layer 
5 Component, Configuration Manager Component, and DBConnect Component, 

Java/JavaScnDt Component 

Figure 6 iUustrates a flow diagram for providing infonnation on a synchronized 
10 event on a pbrality of client apparatuses in accordance ^with one ^bodiment of the 
present invention. First, in operation 600, a plurality of client ^aratuses are 
connected via a network, as set ford earlier. Next, an application program is 
embedded on a site on the network in operation 602. Such application program may 
take the form of a JAVA applet, and the site may include a website on the IntemeL 

15 

In use^ infonnation is requested from a server on fhe network utilizing the 
application program. See operati.on 604. Such information relates to an event to be 
played back simultaneously on the client apparatuses and m^ include general 
information such as a start and stop time of the even^ or more spedfic information 
20 about the ev^ itself 

iti response to such request, a script is received for displaying fixe information. Note 
operation 606. The script may take any form such as Perl, KBXX (on IBM 
mainframes), and Tcl/Tk, and preferably includes a JAVAscript 

25 

In one embodim^t of the present invention, the JAVA ^plet may be fiirth^ 
adapted to send a request to retrieve conomand information from the s^er for use 
with a playback device of one of the client ^paratuses. The commands may be 
adapted to playback the event on the playback device simultaneous with the 
30 playbadcofthe event on the remaining client apparatuses. Farther, tihe commands 
may include a start time when the playback of the event is to begm on each of the 
client apparatuses. 
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The JAVA applets and JAVAscript are used to communicate with the playback device 
of the clieiit apparatuses. In one embodiment, the playback device includes a 
PCFriendly TM video player manufactured by luteractual ®. 

5 

The Java ^let is embedded within a web page and uses HTTP protocol to 
communicate to the synchronization server. The appl^ could request event 
information from the server, and display it to the user via JavaScript. The ^plet 
could also send a ^'BroadcasiVtdeoEvenf* request to retrieve DVD commands that 
10 can be passed to the video component, as set fordi hereinabove. 

Synchronizer Component 

Figure 7 illustrates a method for creating a synchronizer object in order to playback 
15 an event simultaneously on a plurality of chent apparatuses. The synchronizer object 
is portion of the software that actually implements the synchronization procedure. 
First, in operation 700, a request is received utilizing a netwo± for viewing an event. • 
Next, the request is queued in memory in operation 702. 

20 in response to tibie request, in operation 704, an object is created which is adapted to 
pl^ack the ev^t on a client apparatus simultaneous with fte playback of the event 
on the remaining client 85>paratuses upon the receipt of an activation siguaL As an 
option, the activation sigua] may be provided using a dock of ttie client q>paratus, or 
located at a different location, i.e. server. To accomplish tins, the object identifies a 

25 start time when the playback of the event is to begm on each of the client 
apparatuses. 

In operation 706, the object is sent to one of the client apparatuses utilizing the 
network for bemg stored thereia In accordance with a primary aspect of the present 
30 invention, the object may be adapted to pl^ack the event which is stored in 

memory of the chent apparatus. This may be accomplished by activating a digital 
video disc (DVD) player. 
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Jn summary, when the SynchroBiz^ component receives a '^BroadcastVideoEvenr 
from flie applet, it then places the request in the thread queue for processing. To 
process a request, the thread creates a "call back" object, if one does not exist for 
5 this event The thread then adds the request to the "call back" object queue. This 
"call back" object will be invoked when it is time to play the DVD. The 
Synchronizer component creates a Call Back COM object, LayerSink. The 
Synchronizer component is also responsible for creating the LayerFactory interface 
which will be set forth hereinafter in greater detail. 

10 

Laverlmpl Component 

Figure 8 illustrates a flowchart for affording a scheduler object ad^ted to facilitate 
the playback of an event simultaneously on a plurality of networked client 
1 5 apparatuses. • The present method ensures that critical' information is tracked during 
the synchronization of the event* Such critical information not only ensures proper 
synchronization, but also enables various peripheral features. 

First, in operation 800, various values are determined including a current time, a 
20 start time when an event is to start, and a stop time when the event is to end. 

Thereafter, a length of the evmt is calculated based on the start time and the stop - 
time in operation 802. As an option, the current time is det^iined by querying a 
clock of one of tihe client q)paratuses. 

25 If any portion of the length of the event takes place during a predetermined threshold 
period, a command is stored in memory in operation 804. The command may be 
adapted to automatically begin playing back the event at the start time. In one 
embodiment, the threshold period includes the time the users can be queued before 
the event As an option^ chapter information may be stored in the memory if any 

30 portion of the length of tiic event takes place during the predeteramied threshold 
period. This allows the command to automatically begin playing back the event at a 
predetermined ch^ter. 
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In operation 806, a loop is created at the stait time during which a lapsed time of the 
event is tracked This infomation may be used for various tracking pmposes to 
decide when to issue commands to the user. In another embodiment, a second loop 
5 may be created upon the beginning of a ch^ter during which information on a next 
ch^ter is retrieved. 

The "call back" obj ect (LayerSink) is thus responsible for creating and 
ccmmunicating with the Layerlmpl componesit Ihe Layerlmpl component acts as a 
1 0 scheduler, def ennining when to issue commands to the user. 

Layerlmpl will issue different DVD commands, based on the type of decoder (he 
user has in their PC. Layerlmpl will differentiate between the decoders by using the 
decoder information submitted from the client The Layerlmpl vnH pass the correct 
1 5 DVD command to the client, based on the decoder's c^abilities. For example, if 
the decoder does not support the TimePlay event, fh^ the server may send a 
ChapterPlay ev^t and wait appropriately. 

The following is an enumerated summary of the steps the conq)onent uses to 
20 determine when the users will receive the DVD commands: 

1. Retrieves the cuxrent time, and the tim&the event starts and ends. 

2. Calculates the length of the event 

3« If the event is within a threshold period 9*e. the time users can be queued before 
25 the ev^t), then store the first DVD conmiand in memory. Also, store the Chapter 
information in memory. 

4. Create a loop ^ processes request until the event has conipleted 

5. In the loop, calculate the I^sed time of the event 

6. In the loop, retrieve the next che^er informadoxt 

30 7. Create another loop that will loop until time for the next ch^ter to be played. 

8. When the next chapter is ready to play, send the command that was retrieved from 
the Chj^ter table. 
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Busincss Layer Component 

Figure 9 is a flowchart delineating a method for identifying a plurality of events 
5 which are played back simultaneously on a plurality of networked client ^paratuses. 
Tbis features is important since a host server may be synchronizing more than one 
event at once, or duiing overlapping times. Such events must therefore be 
distinguished. 

10 First, in operatiDn 900, aplurality of events are stored in memory on apluralityof 
client apparatuses. Each of the events is assigned a unique identifier which is stored 
in file memory. 

In operation 902, the client ^jparatuses are adapted to be coupled to a host computer 
15 via anetwork, as set forth hereinabove. In operation 904, the identifier of the event 
which is stored in the memory of the client ^paratuses is then retrieved utilizing the 
netvt^oik. Such identifier is subsequently con^ared with an identifier of a scheduled 
event, as set forth in operation 906. If the comparison renders a match, the playback 
of die event is begun on the appropriate client apparatuses. Note operation 908. 

20 

CbusinessLayer thus differentiates events by the disk and location ids, iq>loaded by 
the client to guarantee backwards compatibility. As set forth earli^, late arrivals can 
always re-sync with fee event. 

25 Configuration Manager Component 

Figure 10 shows a flowchart delineating a technique for identifying playback devices 
of a plurality of client £^aratuses ^ch are networked to simultaneously playback 
an event The present technique is important since the playback devices of the 
30 various client ^paratuses may differ in make and model. Urns, different commands 
are required therefor. 
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la operatioii 1000, a type of the playback devices of the clirait j^paratuses is first 
identified. Such **type" may refer to a make, model, or any other distinguishing 
characteristic of the particular playback devices. A command associated with the 
identified type of the playback device is thra looked up in a look-up table. Note 
5 operation 1002. Such table may be located at the host server, or at any other location 
such as the client apparatuses. 

Thereafter, in operation 1004, the conunand is sent to the corresponding client 
apparatus for beginning the playback of the event simultaneously with the playbade 
10 of the event on each of the remaining client apparatuses. 

This congjonent is thus responsible for identifying what type of reference player is 
hosting the event The reference player can be the database, which contains the 
DVD commands or a real time player. When the initial DVD is command is 
15 requested, the "Synchronize^ table is queried for the host type. From that point 
forward, the scheduler would know JBrom whom to receive data. 

DBConnect Component 

20 This component is responsible for communicating with the Synchronizer tables, and 
for providing access methods for the retrieved data. All interaction firom the tables is 
on a read-only basis. The Layerlmpl component communicates with this component 
to retrieve DVD commands and ev^ infonnation. 

25 Even though current implementation may be based on a Microsoft platform, bard 
dependencies on Microsoft or any other 3rd-party development tools may be 
avoided. To address such issues, the following considerations may be made 
throughout the code: 

30 MFC specific code may be avoided Instead, STL may be used. ATL and/or MFC 
code may be encapsulated into separate classes and portioned from the rest of the 
code. Class implementations may use aggregation pattern to delegate business logic 
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to the portable classes. Database coimection classes may be s^arated and the 
communication protocol may be separated with respect to portability to Oracle and 
other platforms. 

5 Figures 11 and 12 illustrate the order of events among the various components of the 
present invention, hi particular, Figure 11 illustrates the manner in which a layer 
fectory is created. As shown, an event is first checked in a database server after 
which a business layer is created in a WEB s&yet in a manner set forth hereinabove. 
The foregoing conaponents are then created. Figure 12 illustrates the manner in 
1 0 which user requests are processed. As shown, communication is afforded with the 
video player on the client machine by means of JAVAscrfpt and JAVA applets. The 
WEB server, in turn, communicates DVD commands to the video player via the 
JAVA applets, and also interfaces the database server via the various components 
thereof which were set forth heieinabove. 

15 

Altemate Embodiments 

To support fhtuic enhancements, further components may be included with extendibility 
as the major objective. Various fiiture enhancements of the product and how they will 
20 be addressed will now be set forth. 

Hosted Real Time Players 

While spirals may retrieve pre-recorded DVD conunands frdtn the database, 
25 alternate spirals may support a consumer as a host The architecture may also 

support plug-in components. Altemate spirals may support the RealTimeComector 
component, \>ri3ich accepts host user request and forwards them to the clients. The 
instant architecture supports the DBConnector which accepts events fix)m ttie 
database. 

30 

Keep Alive Connections 
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Clients may maintaiu connections throughout the event This allows the host to send 
a various number of commands to the client of the event Although the spiral 
disconnects users once a PLAY command has been issued, the Synchronizer class 
(which will be set forth later) adds each connection to a Thread Pool. This pool of 
5 connections can be left open during the life of the event 

Logging Participants 

Each request may be logged into the database to provide a reference for the iutare. 

10 

DVD Positioning 

As an option, connections may be pooled to allow the synchronization server to 
direct consumer's machines to the certain locations througihout the entire event 

15 

Synchronization evrats in alternate spirals may be defned as a combination of play 
from location event and the actual event This way, one describes each event in the 
urtambiguousw^ on the cHent side and synchronizes it with the serv^. For 
example^ a situation may be considered wh^e one &st forwards after a movie is 

20 played for 15 mig and thereafter plays the scene in the movie. Ih such situation, one 
has to submit the information to the client player, indicating that it flayer) has to 
start time play from 15 miTi into the movie and fast-forward to the certain location. 
A better way would be to analyze what is the next event aflear fast forwarding 
occurred and perform a combination for the play fiom location and next event This 

25 design would require significant changes to Aie client infiastructure, including video 
object^ remoteagent mipravider and should be taken into consideration in any 
alternate client design* 

Classes/Component Diagrams 

30 



Figures 13-16 illustrate various class/component diagrams. In particular. Figures 13- 
16 illustrate a Synchronizer Class Diagram 1300, Layerhnpl Class Diagram 1400, 
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Business Lay^r Class Diagram 1500, and DBConnect Qass Diagram 1600, 
respectively. 

Sequence Diagrams 

5 

Figure 17 illustrates a logical sequence diagram 1700. As shown, when the server 
receives a user request, it analyzes the authentication infonnation of the request 
(date/time, disc id, user id, and BCA number) and the appropriate synchronization 
event stored in the database. The database contains an event start threshold value 
1 0 measured in milliseconds. Hiis threshold defines the amount of time prior to an 
event that a consumer is eligible to ^'connect** for the start of the event 

If the date/tnne of the user request lies within the event start threshold, the user is put 
into wait queue and receive the appropriate data when the time elapses. Note stq)S 
15 1,2,3,5,6,7 of the Logical Sequence diagram. Otherwise, a message is sent 

infoiming the user when the ev^ will occur. Note step 4 of the Logical Sequence 
diagram. 



Server side collaboration diagram 

20 

Figure 18 illustrates a logical sequence diagram 1800 that shows server side 
collaboration. As shown, server ISAPI extension receives a BroadcastVideoEvents 
request It caDs IA_BusinessServer via BegmProcess, to retrieve configuration 
information. Configuration information contains a playback connector. Playback ' 
25 connector idoitifies whether die server will have to communicate with a lefoence 
player or will it per&rm playback fiom the database. 

At step 6, ISAPI extension will call JAJBusinessSen^er CompareTime method and 
based on the results will send to the usct a predefined web page indicating to retry 
30 later or return control to the web server, notifying it (web server) to keep the 

connection open. At this point connection is pooled and will be processed by the 
IA_BusinessServer at a time of the evait 
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Client CoUaboratioD Diagram 

Figure 19 illustrates a logical sequence diagram 1900 showing client side 
5 collaboration in accordance with one embodiment of the present invention. 

Classes/Interfaces Definition 

Definitions of one ^bodiment of tiie various classes associated vnfix the software which 
1 0 implements the present invention will now be set forth. 

Class Appletl 

Purpose: 

15 

This is the class that impl^ents the applet The browser will use it to bootstrap otu: 
applet 

Responsibilities: 

20 

" Request a BroadCastVideo event and to gather event status information. 
Collaborations: 
25 BroadCastEvent, Cniaicrypt 

Base class and implemented interfaces: 
Javax.Applet 

30 

Public interface: 
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getChapter Returns the current chapter the refeence player is playing. 
Return type: String 
Parameters: void 
Pre-conditions: None. 
5 Post-conditions: None. 

getntielnfo Returns the cunent title the reference player is playing 
Return type: String 
Parameters: void 
10 Pre-conditions: None. 
Post-conditions: None, 

getStartUme Returns the time the event is scheduled to start 
<SS:MMaffl-DD:MM:YYYY> 
15 Return type: String 
Parameters: void 
Pre-conditions: None. 
Post-canditions: None. 

20 getStartTimeSec Returns the time the event starts in seconds. 
Return type: String 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

25 

getSfartTimeMinRetQins the time the event starts in minutes. 
Retum^e:. String 
Parameters: void 
Pre-conditions: None. 
30 Post-conditions: None. 

getStartTimeHrRetums the time the event starts in Hours. 
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Retumtype: String 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

5 

GetStartlimeDay Returas the time the event starts in days. 
Return type: String 
Parameters: void 
Pre-conditions: None, 
10 Post-conditions: None. 

GetStarflimeMntb Returns the time the event starts in montiis. 
Return type: String 
Parameters: void 
15 Pre-conditions: None. 
Post-conditions: None. 

GetStartTimeYr Returns the time the event starts in year. 
Return type: String 
20 Parameters: void 

Pre-conditions: None. 
Post-conditions: None. 

GetLenOfBvent R^ums flie length of the event 
25 Return type: String 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 



30 



GetExpiredTLme: Returns l^se time of the event. 
R^um type: String 
Parameters: void 
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Pre-conditions: None. 
Post-conditions: None. 

getServerTime: Returns the servers curxeat time <SS:MM:HH:DD:MM:YYYY>. 
5 Return type: String 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

10 getServciTimeSec: Returns the servers current in seconds. 
Return type: String 
Parameters: void 
Pre-conditions: . None. 
Post-conditions: None. 

15 

getServerTimeMin: Returns the servers current in minutes. 
Retum type: String • 
Paramet^: void 
Pre-conditions: None, 
20 Post-conditions: None. 

getServerTimeHr : Returns fte servers current in hours. 
Retum type: Struag 
Parameters: void 
25 Pre-conditions: None. 
Post-conditions: None. 

getServeiTlmeDay: Returns the servers current in day. 
Retum type: String 
30 Parameters: void 

Pre-conditions: None. 
Post-conditions: None. 



} 
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getServerTimeMnth: Returns the servers current in month. 
Return type: String 
Parameters: void 
5 Pre-conditions: None. 
Post-conditions: None. 

getServeiTimeYr: Returns the servers curreat in year. 
Return type: String 
1 0 Parameters: void 

Pre-conditions: None. 
Post-conditions: None. 

startProc: Calls the ISAPIs *'ServerInfo" method. 
15 Return type: void 

Parameters: String disk id. String location id 
Pre-conditions: None. 
Post-conditions: None. 

20 msgEvent: Calls BioadCastEvent applet 
Return type: void 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

25 

Class BroadCastBvent 
Purpose: 

30 This is the class that invokes the Synchronizer. 
Responsibilities: 
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« Sets the JavaScript with the command returned from the server. 
Collaborations: 
CmEncrypt 

Base class and implemented interfaces: 
Java.Thread 
Class CDBCotmect 
Purpose: 

This is the class provides apuhlic interface for components to request infoimation 
from the DB tables. 

Responsibilities: 

■ Opens the database and Synchronizer, Chq>ter_pisk tables. 

* Queries the Synchronizer by the specified disk id and location id. 

■ Queries flie Oiapter^Disk by disk id. 

■ Provides fhe next chapter that is scheduled to play. 

■ Queries the Decoder_Capabilities table to deternrine if the requested player is 
time or ch^t^play. 

Collaborations: 

DBSyncSet 

DBReferenceSet 

CDBChapterSet 
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CDecodeiCapabilities 

Base class and implemented interfaces: 

Public interface: 

Get_NextChapter: Returns the next chapter to play. 
Return type: String 

ParamctCTs: long time, long title, BSTR Chapter 
Pre-conditions: None. 
Post-conditions: None. 

chkEvent: Checks if an event is scheduled for the disk and location id 
Return type: String 

Parameters: long time, long title, BSTR Chapter 
Pre-conditions: None. 
Post-conditions: None. 

get^initialDVDConimand: Returns the first DVD command to play. 
Return type: String 
Parameters: BSTR& 
Pre-conditions: None. 
Post-conditions: None. 

get^nextDVIKromniand: Returns the next DVD command to play. 
Return type: String 
Parameters: . BSTR& 
Pre-conditions: None. 
Post-conditions: None. 



decoderArray: Returns an array of decoder types. 
Return type: String 




Parameters: long **, long ** 
. Pre-conditions: None. 
Post-conditions: None. 

5 Class CCConfigMgttmpl 

Purpose: 

This is the class provides a public interface for components to detennine fte type of 
10 reference player hosting the event 

Responsibilities: 

■ Opens the database and Synchronizer, ChapterJDisk tables. 
15 * Queries the Synchronizer by the specified disk id and location id, 
» Stores Xb& reference player type. 

Collaborations: 

20 CConfigMgrRecSet 

Base class and implemented interfaces: 

Public interface: 

25 

get_bD5tType: Returns the reference player host type. 
Return type:. String 
Parameters: short 
Pre^nditions: None. 
30 Post-conditions: Nona 

Class threadFnnctor 
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Ptapose: 

This class provides a threading model that classes can use to derive. 

5 

Responsibilities: 

■ Calls the CreateBvent fimctioD, which opens a named or xumamed event 
ohjec* 

10 ■ Calls Jbeginthread, which creates a thread begins execution of a routine at 
start_address* The routine at start_address must use &e cdecl calling 
conv^ition and should have no return value. When the thread returns from 
fliat routine, it is tenninated automatically. 

■ Calls the WaitForSingJeObJect function, which checks the current state of the 
15 specified object If the object's state is nonsignaled, the calling thread enters 

an efficient wait state. 

■ Calls the ResetEvent function, which sets the state of tiie specified eveot 
object to nonsignaled 

■ The state of an evoit object remains nonsignaled until it is explicitly set to 
20 signaled by the SetEvent or PulseEvent function. 

Collaborations: 

CConfi^erRecSet 

25 

Base class and implemented interfaces: 

Public interface: 

30 start: Starts the thread. 
Return type: void 
Parameters: void 
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Pre-conditions: None. 

Post-condidons: None. 

stop: Stops the thread. Calls CloseHandle for the fliread and event 
5 Return type: void 
Parameters: void 

Pre-conditions: None. 

Post-conditions: None. 

10 Class isapithiead 

Puqjose: 

This creates an IS API thread. 

15 

RespoTtsibilities: 

* Adds a request to a vector. 

" Creates the sink object 

20 " Stores &e request into sink object 

■ S^ids the time information to JavaScript 

Cottdborations: 

25 LayerSink 
factoiySink 

Base class and implemented interfaces: 

30 threadFunctor 

Public interface: 
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addrequest: Adds the request to its vector. 
Return type: void 
Parameters: void 



Pre-condidons: 



None, 



Post-conditions: 



None. 



getBLayerlnfo: Resgponsible for getting infoimation about the event 
Return type: void 

Parameters: std:string&^td::strmg&, ChttpServerContext* 



Class factorvSink 
Purpose: 

Manages the layerSink and bnsinessLayeiProp objects- 
Responsibilities: 

■ Stores a layerSink object 

» Returns the "'btisinesssOLayi^'Prop" <Business Layer Properties> 

■ Creates the '1>nsines$LayeiProp'* <Bu'siness Layer structuro 

Collaborations: 

LayerSink 
businessLayerProp 



Pre-conditions: 
Post-conditions: 



None. 



None. 



Base class and implemented interfaces: 
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Public interface: 

construct: Stores a layerSink object. 
Return type: void 
5 Parameters: void 

Pre-coaditions: None. 
Post-conditions: None. 

notift^CreateLayer: Responsible for creating a "businessLayerProp**. 
10 Return type: void 

Parameters: BSTR, BSTR, DATE, DATE. LONG 
Pre-conditions: None. 
Post-conditions: None, 

15 Class layerSink 

Purpose: 

layerSink rq>reseQts a sink interface and stores a queue of requests. It creates a 
20 connection point object 

ITiis call back object, allows a^chronously processing.' 

Responsibilities: 

25 ■ Acts as the client sink object. 

> Sends the results to the user 

' Creates the "BusinessLayi^ and makes it a connection point object. 

■ Closes the users connection. 

■ Creates a Factory interface by calling "createOFactory". 
30 ■ Creates a connection point for the factory, 

■ Stores the LayerSink in the FactoiySink object 
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* Creates a connection point (call back) by calling AtlAdvise, between the 
connection point container and the client sink object This allows the client 
to receive events. 

■ Calls the connectable objects "getServerLayer". This method fires an event to 
5 the clients sink object. 

■ Create a business layer, 

■ Store the request in its vector. 

■ Release the Sink Object (client) 

■ Calls AtlUnadvise to terminates the ability of the client to receive events. 

10 

Collaborations: 

Base class and implemented interfaces: 
15 Public interface: 



constracf: Creates a connection point 
Return type: void 
Parameters: void 
20 Pre-conditions: None. 
Post-conditions: None. 



addReqaest: Adds the request to its vector. 
Return type: void 
25 Parameters: BSTR, BSTR, DATE, DATE, LONG 
Pre-conditions: None. 
Post-conditions: None. 



createBusinessLayer: Creates a business layer. Create the connection point . 
30 Return type: void 

Parameters: businessLayerProp & 
Pre-conditions: None, 
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post-conditions: None. 

updatetime: This call back function translates the time and sends the command to 
theiiser. 
5 Return type: void 
Parameters: longjong 
Pre-conditions: None. 
Post-conditions: None. 

10 Class CBusinessLaver 

Purpose: 

Creates a layerthread object This object is responsible for providing access methods, 
15 vrfiich provide event infomaation. 

Responsibilities: 

» The "Synchronizers" createBusinessLayer mefliod creates a class object from 
20 the "IBusinessLaya:" interface. <rhe class object is part of the Lay^Iropl 

projects * 

■ The BusinesLayers class object <m_ilayer> calls its "Mtialize" method. 
<Note: m_ilayer is the connection point object. It identiiSes the "Sink 
Ihterface" 

25 ■ K thai calls the "Mtialize" method of flie connection point 

■ The "Initialize" mefliod then calls the "ChkValidEvent" method, which then 
creates a layertfaiead object 

Collaborations: 

30 



CBnsinessLayer 
layerthread 
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Base class and implemented interfaces: 
Public interface: 

5 

InitiaUze: CaDs (he "ChkValidEvent" method which kicks of a layer tiiread. 
Return type: void 
Parameters: void 
Pre-conditions: None. 
10 Post-conditions: None. 

Class laverthread 

Purpose: 

15 

This object acts as a scheduler, processing request &om its queue* 

Responsibilities: 

20 ■ Send DVD commands to the user. 

■ "Syncs" up late comers to Ike events. 

Collaborations: 

25 CBusinessLayer 
CDBConnect ' 

Base class and implemented interfaces: 

30 Public interface: 

startThread: Processes requests from the queue 
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Retiirn type: void 
Parameters: void 
Pre-conditions: None, 
Post-conditions: None. 

Class CLaverFactorv 

Purpose: 

Hiis object manages businesslayer objects. Business layer objects communicate with 
the reference player and notify the user which DVD command to play. 

Responsibilities: 

■ Send DVD commands to the user, . 

■ "Syncs" up late comers to the events. 

■ This object hnplements the npjL^wFactoiy interface. 

■ This COM object is the servers Connectable Point object. 

■ This server object supports connections to sink interfaces. These sink 
interfaces reside on the client side and are equival^t to the "call back" 
functions in Windows. 

Collaborations: 

CBustnessLayer 
CDBConnect 

Base class and implemented interfaces: 

Public interface: 
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getServerLayer: "Fires" an event to create a business layer with the properties 
retrieved from the pipe object 
Return type: void 
Parameters: void 
5 Pre-conditions: None. 
Post-conditions: None* 

pnt^setjayer: call the "C3LayerFactoryImpl" addQ method. Supplying the 
"businesslayer" object 
10 This win added to shared niemoiy queue and written to a file. 
Return type: void 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

15 

HnalConstruct: Calls the "CLayetFactoryLnpr' FinalConstruct COM class object. 
Return type: void 
Parameters: void 
Pre-conditions: None. 
20 Post-conditions: None. 

Although only a few embodiments of flie preset invention have been described in 
detail herein, it should be understood that tibe present invention may be embodied in 
many other specific forms without departing 6om the spirit or scope of the 
25 invention. Therefore^ the present examples and ^bodiments are to be considered as 
illustrative and not restrictive) and the invention is not to be limited to the details 
given herein, but may be modified within die scope of the app wded claims. 



-54- 



CLADMS 

What is claimed is: 



1 1 . A method for synchronizing an event on a plurality of a client ^paratuses, 

2 comprising the steps of: 

3 (a) providing an event stored in a memory storage device; 

4 (b) connecting the client apparatuses and a host con:q)uter to a network; and 

5 (c) transmitting infoimation from the host compute- to the memory storage 

6 device utilizing the network for allowing the simultaneous playback of the 

7 event on each of the client apparatuses. 

12. A method as recited in claim 1, wherein the event includes a video and audio 
2 presentation. 

13. A method as recited in claim 2, wherein the event includes at least one of a 
2 movi^ a concert, and a theatrical event 

14. A method as recited in claim 1, herein the network is a wide area netwoidc 

15. A method as recited in claim 1, wherein the information includes a start time 
2 when the playback of Uie event is to begin on each of the client apparatuses. 

16. A method as recited in claim 1 > wherein the information includes an ©ading 

2 time when the playback of the event is to end on each of the client 

3 apparatuses. 

1 7. A method as redted in claim 1, wherein the memory storage device includes 

2 a digital video disc (DVD) player. 

1 8. A method as recited in claim 7, wherein the infonnation includes chapter 

2 information associated with the DVD. 
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19. A meliiod as recited in claim 1, and further corapiising the step of receiving 
2 input fiom the user, and altering the playback based on the input 

1 10. A compute program embodied on a coinputer readable medimn for 

2 synchronizing an event on a plurality of a client apparatuses, comprising: 

3 (a) a code segment for providing an event stored in a memory storage device; 

4 (b) a code segment for connecting the client apparatuses and a host computer to 

5 anetwoik;and 

6 (c) a code segment for transmitting information firom the host computer to the 

7 memory storage device utilizing the network for allowing the simultaneous 

8 playback of the event on each of the client apparatuses. 

1 11. A computer program as recited in claim 10, wherein the evoat includes a 

2 video and audio presentation. 

1 12. A computer program as recited in claim 1 1, wherein the event includes at 

2 least one of a movie, a concert, and a theatrical event 

1 13. A con5)uter program as recited in claim 10, wherein liie network is a wide 

2 area network. 

1 14. A computer program as recited in claim 10, wherein ttie information includes 

2 a start time when the playback of the event is to begin on each of the client 

3 apparatuses. 

1 15. A computer program as recited m claim 10, wherein the information includes 

2 an ending time when the playback of flie event is to end on each of the client 

3 apparatuses. 

1 16. A computer program as recited in claim 10, wherein the memory storage 

2 device includes a digital video disc (DVD) player. 
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1 17. A computer piogram as recited in claim 1 6» wherein the in&rmation includes 

2 chapter information associated with the DVD. 

1 18. A coiiq>uter program as recited in claim 10, and further comprising a code 

2 segment fox receiving input &om the user, and altering the playback based on 

3 the mput 

1 19. A system for synchronizing an event on a plurality of a client q)paratuses, 

2 comprising: 

3 (a) logic for providing an event stored in a memory storage device; 

4 (b) logic for coimecting the client apparatuses and a host coii5}uter to a networlq 

5 and 

6 (c) logic for transmitting information fiom the host con^uter to the memory 

7 storage device utilizing the network for allovwng the simultaneous playback 

8 of the event on each of the client ^paratuses. 



SYSTEM, METBOD AND ARTICLE OF WUUVUFACTURE FOR 
EXECUTING A MULTIMEDIA EVENT ON A PLURALITY OF CLIENT 
COMPUTERS USING A SYNCHRONIZATION HOST ENGINE 

ABSTRACT 

A system, method and article of manu&cture are provided for synchronizing an 
event on a plurality of a client apparatuses. Fiist, an event is stored in a memory 
storage device. The cli^ ^aratuses and a host computer are adapted to he 
connected to a network. In operation, information is transmitted from the host 
computer to the memory storage device utilizmg the network. This allows for the 
simultaneous playback of the event on each of flie cli^t apparatuses. 



PROVIDING AN EVENT STORED IN MEMORY ON A PLURALITY OF CLIENT APPARATUSES, 
WHEREIN THE CUENT APPARATUSES ARE ADAPTED TO BE CONNECTED TO A HOST 
COMPUTER VIA A NETWORK 
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TRANSMITTtNG INFORMATION FROM THE HOST COMPUTER TO THE CUENT 
APPARATUSES UTIUZING THE NETWORK FOR AUOWING THE SIMULTANEOUS PLAYBACK 
OF THE EVENT ON EACH OF THE CLIENT APPARATUSES 
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Figure 2 



PROVIDING AN EVENT STORED IN NEMORY ON A PLURAUTY OF CUENT APPARATUSES, 
WHEREIN THE CUENT APPARATUSES ARE ADAPTED TO BE CONNECTED TO A HOST 
COMPUTER VIA A NETWORK 



STORING INFORMATION ON THE HOST COMPUTER FOR ALLOWING THE SIMULTANEOUS 
PLAYBACK OF THE EVENT ON EACH OF THE CUENT APPARATUSES 



ALLOWING THE INFORMATION TO BE DOWNLOADED UTILIZING THE NETWORK FOR 
PLAYBACK AFTER THE SIMULTANEOUS PLAYBACK 
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CONNECTING A PLURALITY OF CLIENT APPARATUSES VIA A NETWORK 
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SIMULTANEOUSLY PLAYING BACK AN EVENT ON THE CUENT APPARATUSES UTILIZING 

THE NETWORK 
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OVERLAYING MATERIAL DURING THE PLAYBACK OF THE EVENT BASED ON INPUT 
RECEIVED FROM AT LEAST ONE OF IHE CUENT APPARATUSES 
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Figure 4 



CONNECTING A PLURAU7Y OF CUBm APPARATUSES VIA A NETWORK. WHEREIN AN 
B/Bm IS STORED IN MEMORY ON THE CLIENT APPARATUSES 
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SIMULTANEOUSLY PLAYING BACK THE EVENT ON THE CUENT APPARATUSES UTtUZING 

THE NETWORK 
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RECEIVING A REQUEST FROM Ot^ OF THE CLIENT APPARATUSES DURING THE 
SIMULTANEOUS PLAYBACK TO BE INCLUDED IN THE SYNCHRONIZED EVENT 
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TRANSMimMQ INFORMATION TO THE REQUESTING CUENT APPARATUS UTILIZING THE 

NETWORK FOR IDENTIFYING A LOCATION IN THE WEMORY WHERE THE EVENT IS 
CURRENTLY BEING PLAYED BACK SO AS TO ALLOW THE SIMULTANEOUS PLAYBACK OF 
THE EVENT ON THE REQUESTING CLIENT APPARATUS 



508 



Figure 5 



CONNECTING A PLURALTTY OF CUENT APPARATUSES VIA A NETWORK 
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EMBEDDING AN APPUCATION PROGRAM ON A SITE ON THE NETWORK 
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REQUESTING INFORMATION FROM A SERVER ON THE NETWORK UTILIZING THE 
APPLICATION PROGRAM, WHEREIN THE INFORMATION RELATES TO AN EVENT TO BE 
PLAYED BACK SIMULTANEOUSLY ON THE CUENT APPARATUSES 
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RECEIVING A SCRIPT FOR DISPLAYING THE INFORMATION 
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Figure 6 



RECEIVING A REQUEST UTIUZING A NETWORK FOR VIEWING AN EVENT 
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QUEUING THE REQUEST IN MEMORY 
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CREATING AN OBJECT IN RESPONSE TO THE REQUEST. THE OBJECT ADAPTED TO 
PLAYBACK THE EVENT ON A CLIENT APPARATUS SIMULTANEOUS WITH THE PLAYBACK 
OF THE EVENT ON THE REMAINING CUEMT APPARATUSES UPON THE RECEIPT OF AN 
ACTIVATK)N SIGNAL 
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SENDING THE OBJECT TO ONE OF THE CUENT APPARATUSES UTIU2NG THE NETWORK 
FOR BEING STORED THEREIN 
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T 



Figure 7 



DETERMINING A CURRE^^' TIME. A START TIME WHEN AN EVENT IS TO START, AND A 
STOP TIME WHEN THE EVENT IS TO END 



800 



CALCUIATINQ A LENGTH OF THE EVENT BASED ON THE START TINE AND THE STOP TIME 
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STORING A COMMAND IN MBUIORY IF ANY PORIIOM OF THE LENOTH OF THE EVENT 
TAKES PLACE DURING A PREDETERMINED THRESHOLD PERIOD 
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Figure 8 



PROVIDING A PLURAUTY OF EVETfTS STORED IN MEfWORY ON A PLURAUTY OF CUENT 

APPARATUSES, THE EVEhrTS EACH HAVING A UNIQUE IDENTIFIER ASSOCIATED 
THEREWTTH AND STORED IN THE MEMORY. WHERBN THE CL^E^^• APPARATUSES ARE 
ADAPTED TO BE COUPLED TO A HOST COMPUTER VIA A NETWORK 
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